Memory management is critical to the proper operation of computer programs. Failure to free memory results in “leaks” or ever-increasing use of memory until eventually the application will malfunction or fail. In addition, the performance of other applications on the computer will be affected as available memory is squandered.
Programs written in languages such as C or C++, have no memory intelligence. For example, C programs do not automatically free memory until the application is completed. At times, an application may run for weeks or even months; an error created by a failure to free memory may not surface until a long time after the error was introduced.
Java® provides much more intelligence with respect to memory in its programming capabilities, but programmers still make errors at times in managing memory functions within their program code. Finding and correcting such an error is tedious and time consuming for programmers.
Numerous approaches have been proposed to solve this problem. For example, JAVA® removes responsibility for memory management through the use of “garbage collection,” but improperly written applications could still cause leaks. Run-time tools to analyze use of memory are sometimes employed, tracking memory that is allocated and freed, then reporting memory still remaining.
Application writers often keep a list of allocated memory for their function then free the allocated memory on exit. In some cases, a “memory manager” is implemented for use across an application. While these approaches can help to track and report allocations and their matching calls to free the memory, it is still up to the application programmer to build the test cases to prove that all leaks are eliminated.
Another problem related to proper memory management is freeing only the memory that has been allocated. In some cases, memory corruption can result if an application calls the “free” function, and then passes an address that has not been allocated or that has already been freed. This memory corruption can be very difficult to debug because the symptom does not appear until long after the error cause.
Another memory management problem is caused if an application allocates space to contain “n” bytes but then stores “n+1” or more bytes into that space. This is generally called memory corruption. The data following the allocated space can sometimes be critical to proper execution of the program. However, any symptom of this error will not be detected until that data is used. Detection of this error is commonly supported by compilers, but requires additional calls to be inserted into the code and is only operational with a “debug” build.
Memory management solutions typically depend on the application programmer to either write perfect code (at least in the area of memory management), or to diagnose problems after the code is written then correct the code one case at a time. This approach can never be proven to eliminate all leaks.
What is therefore needed is a method for removing the burden of detecting memory management errors from the program developer and for providing documentation for memory management functions and their performance within the program developer's code. The need for such a system has heretofore remained unsatisfied.